AWS VPC는 Virtual "Private" Cloud의 약자로 논리적으로 격리된 가상 네트워크를 의미한다. 기업이 자체 데이터센터(온프레미스)를 운영하는 것과 유사한 네트워크를 제공하는 것으로, 기본적으로 접근이 불가능하다.

하지만 처음 AWS를 접할 때, 딱히 접근 불가능한 경험을 하지 않을 것이다. VPC를 사용하지 않아서 일까? 그럴 수도 있지만, AWS 활용시 가장 많이 이용되는 호스팅(EC2) 서비스는 VPC 내부에 상주하는 서비스이다. 즉, 높은 확율로 이미 VPC를 활용하고 있었을 것이다.

그동안 VPC 내부에 구성되는 서비스들에 별다른 설정 없이도 접근할 수 있었던 것은 기본 VPC 설정 때문이다. 최초 계정 생성시 AWS는 각 리전에 기본 VPC를 구성해주는데, 이 기본 VPC는 외부와의 접근이 가능하도록 설정되어있기 때문이다.

즉, 기본적으로는 사용자 편의성을 위해 공개된 상태로 제공되니, 이를 원하는대로/내부망으로서 활용하려면(e.g. A 접근은 차단하고 B 요청은 허용), VPC는 어떻게/무엇으로 구성되어 있는지, 어떻게 소통/연결(네트워크)되는지 등을 알아야 할 것이다.

---

VPC

VPC는 AWS 클라우드 내에 논리적으로 격리된 가상 네트워크(공간/영역)를 만드는 기능이다. 각 리전별로 구분되며, 하나의 리전에 여러 VPC가 존재할 수 있다.

인터넷 게이트웨이

이름 그대로, 인터넷과 연결되는 입구라고 생각하면 된다. 인터넷 게이트웨이는 VPC에 사용되는/붙는 서비스로, VPC에 인터넷 게이트웨이가 없다면 VPC 내부에 상주하는 서비스들은 인터넷에 직접적으로 접속할 수 없게 된다. 즉, VPC의 인터넷 게이트웨이 사용여부가 격리되었는지 아닌지를 판별하는 첫번째 기준이다.

서브넷

서브넷이란 서브 네트워크라는 의미로 대규모 네트워크 내의 작은 네트워크들을 말한다. 대규모 네트워크를 분할하여 특정 영역만 사용하는 행위인 것이다. 즉 AWS에서 서브넷이라 함은 VPC(대규모 네트워크)의 부분집합을 말하며 많은 예시 이미지에서도 그렇게 표현 중이다. 다음은 VPC 및 서브넷의 IP 범위에 대한 예시다.

• VPC : 172.31.0.0/16
• Subnet 1 : 172.31.0.0/20
• Subnet 2 : 172.31.16.0/20
• Subnet 3 : 172.31.32.0/20
• Subnet 4 : 172.31.48.0/20

위의 IP 들이 어째서 더 넓은 범위 or 부분 집합임을 의미하는지 이해하려면, CIDR 포스팅을 보도록 하자

그 밖의 AWS 서브넷의 특징으로 단일 가용 영역 내에서만 존재해야 하며, 여러 영역으로 스케일 아웃할 수 없다는 점이 있다. 가용 영역이란 각 리전에 존재하는 실제 물리적 데이터 센터를 의미한다. 즉, 여러 가용 영역에 데이터를 배치하면 정전, 자연 재해 등과 같은 물리적 문제에서 더 안전해질 수 있다.

• 가용 영역 A에 서브넷 a, b 존재 => 가능
• 서브넷 a가 가용 영역 A, B를 사용 => 불가능

라우터

라우터는 컴퓨팅 디바이스와 네트워크를 다른 네트워크에 연결하는 네트워킹 디바이스로, 주로 다음의 3가지 역할을 한다.

1. 라우팅(경로 결정) : 어디로 데이터를 보내야할지 결정한다
2. 데이터 전달 : 선택한 경로의 다음 디바이스에게 데이터를 전달하여 최종적으로 목적지에 도달할 수 있도록 한다
3. 로드 밸런싱 : 경우에 따라 동일한 데이터 패킷을 여러 경로로 보낼 수 있다

이 중 라우팅(경로 결정)이 가장 핵심 역할이다. 이때 라우터는 여러 경로들 중 하나를 선택하는 역할뿐만 아니라, 경로 자체를 만드는 역할도 담당한다. 따라서 라우터가 경로 생성하는 방법과 경로를 선택하는 방법에 대해 알아야 할 것이며, 이를 결정하는 것이 라우팅 테이블이다.

[라우팅 테이블]

라우팅 테이블에는 특정 IP 대역의 요청이 들어오면 어디로 보내야 하는지 정의되어 있다. 예를 들어, 다음의 기본 생성되는 라우팅 테이블로 이해를 해보자.

IP 범위	대상
0.0.0.0/0	인터넷 게이트웨이
172.31.0.0/16	local

※ 경로 관리

테이블에 IP 범위와 대상을 정의해 놓는 것, 1개의 행을 추가하는 것이 경로를 생성하는 것이다. 위의 예시에서는 총 2개의 경로가 존재하는 셈이다. 만일 경로 172.31.0.0/16 | local 를 삭제한다면, local로 이동할 길 자체가 삭제되고, 모든 트래픽은 인터넷 게이트웨이로 나가게 될 것이다.

※ 경로 선택

생성된 경로(규칙)들 중 더 구체적으로 같은 IP 범위가 올바른 경로인 것으로 판단하여 트래픽을 전달하게 된다.

위의 예시 라우팅 테이블을 사용중인 라우터에 172.31.10.0 으로 가길 원하는 요청이 들어왔다고 가정하자. 이 IP는 172.31.0.0/16 범위에 속하지만, 0.0.0.0/0 에도 속한다. 이때 라우터는 더 구체적으로 같은, 172.31 까지 같은 172.31.0.0/16가 더 적합하다 판단하고 local로 요청을 보내게 되는 것이다.

그럼 일치하는 규칙이 아예 없었다면? 경로가 없으니 데이터는 전달될 수 없다. 차단되는 것이다. (위의 예시 테이블에서는, local이 아니라면 모두 인터넷 게이트웨이로 빠지게 될 것이다)

이렇듯 라우터는 데이터 경로를(길을) 만드는/규정하는 핵심 요소이기에, 각 서브넷 별로 1개씩 별도의 라우터를 갖도록 하여 원하는 길을 설정할 수 있도록 설계되어 있다. 이 때 해당 서브넷에 연결된 라우터가 사용중인 테이블에 인터넷 게이트웨이로 향하는 경로가 있을 경우, 이를 "퍼블릭 서브넷"이라고 부르게 되는 것이다. 그 밖에도 NAT 게이트웨이, VPC 피어링, VPN 등으로 향하는 경로(길)이 정의되어 있는지(=존재하는지) 여부가 서브넷의 속성(e.g. VPN 전용)을 결정하는 것이다.

방금 언급했듯, 각 서브넷은 별도의 라우터를 갖는다. 그러나 실질적으로 경로를 판단하는 라우팅 테이블은 논리적 규칙일 뿐이기에, 라우터들이 1개의 테이블을 공유할 수 있다. 실제 AWS VPC Console에서도 라우터 섹션은 존재하지도 않으며, 라우팅 테이블 섹션만 존재한다. 또한 별도의 설정을 하지 않았다면, 기본 라우팅 테이블이(=규칙이) 모든 서브넷에 적용되어 사용되고 있는 것도 확인할 수 있다. 만일 특정 서브넷에는 다른 규칙을 적용하고 싶다면, 별도의 라우팅 테이블을 생성한 후 연결하면 된다.

이처럼 라우팅을 결정하는 실질적인 요소는 라우팅 테이블이기에, 라우터와 라우팅 테이블을 엄연히 다른 존재(개념)이지만, 이와 같이 많은 경우에 혼용되어 이야기된다. 실제로 혼용되어도 크게 문제가 되지 않을 정도로 같은 개념을 가리킨다.

많은 글에서 라우터는 데이터를 "어디로" 보낼지 결정하는 요소라고 언급한다. 이제는 이것이 올바른 표현이라는 것을 이해한다. 하지만 처음에는 이것이 잘못된 표현이라고 생각했다. "어디로" 갈지 결정하는 것은 최초 요청을 시작할때, 요청지점에서 작성한/사용한 URI/IP가 결정하는 것이라고 생각했기 때문이다.
요청시 사용한 URI/IP는 목적지의 이름(주소)인 것뿐이며, 라우터는 그 목적지까지 가는 방향을 안내해주는 역할은 하게 된다. 예를 들어 해외에 위치한 친구 집에 간다고 해보자. 목적지는 출발전부터 이미 알고 있다. 하지만 그곳에 도착하려면? 사람이라면 스스로 지도를 보거나 검색을 통해 해결할 수도 있겠지만, 데이터는 그렇지 못하다. 목적지는 알지만, 그 곳에 도달하려면 어떻게/어디로 가야한다는 안내 없이는 방법이 없는 것이다. 이때 라우터가 길안내자로서 그 곳에 가려면 이 방향으로 가면 된다고 알려주는 역할을 하는 것이다.

NACL

NACL은 Network Access Control List의 약어로, 이름 그대로 네트워크 접근에 대한 통제를 한다. 각 서브넷당 1개씩 존재하며, 서브넷의 수문장 역할을 맡는다. 그러나 NACL자체는 규칙일 뿐이기에, 앞서 확인한 라우팅 테이블과 같이, 모든 서브넷이 같은 NACL(규칙)을 사용하는 것도 가능하다.

NACL도 네트워크 접근을 통제하는 만큼, IP 대역 설정을 통해 접근을 제어한다. 다만 앞서 라우팅 테이블과 그 평가 방법이 다르다. 다음은 NACL의 핵심적인 특징이다.

• 명시적 차단 가능
• 규칙 번호 부여
• stateless

[명시적 차단]

NACL은 유일하게 특정 IP 대역에 대해 차단(deny)이 가능하다. 해커로 의심되는 IP 대역을 차단하는 등의 행위를 가능케 해주는 것이다. 앞서 언급한 라우터나 아래 기술할 보안그룹들 모두 "허용" 규칙만 생성할 수 있다.

그러나 허용 규칙들도 결국 네트워크 통신을 제어하는 역할하는 것이기에, 이들을 잘 활용하면 NACL의 역할을 대신할 수 있는 것 아닌가 싶을 수 있다. 허용해 놓지 않으면 차단이니까. 라우터에 경로가 없으면 차단이니까. 이 방법은 가능은 할지 몰라도, 말도 안되는 수고로움과 복잡성 증가로 인해 사실상 불가능하다 할 수 있다.

예를 들어 모든 IP 대역을 허용하지만 A.A.A.A 라는 IP만을 차단하고 싶다고 하자. 이를 라우터/보안그룹을 이용해 해결하려면, A.A.A.A 미만 + A.A.A.A 초과인 IP 대역들을 허용을 해주어야 한다. 이것만 해도 어질어질한데, 만일 차단해야할 IP들이 여러개라면? 답이 안나오는 것이 느껴질 것이다.

이 문제를 NACL을 이용하면 A.A.A.A 라는 IP만 차단한다는 것으로 가볍게 해결되며, 추후 차단해야할 IP들이 더 생기더라도, 그 IP들만 추가로 차단하면 되는 것이다.

[규칙 번호]

NACL 규칙은 생성시 번호를 부여해야만 하며, 이 번호는 우선순위 판별 용도로 사용된다. 판별 방법은 낮은 번호의 규칙부터 먼저 평가하여, 일치되었다면(=IP 범위에 속하였다면), 그보다 높은 번호의 규칙들은 더이상 평가하지 않는 것이다. 예를 들어 특정 IP 요청이 들어왔으며, NACL 규칙들 중 1번 항목에서 Deny로, 100번 항목에서 Allow로 평가될 수 있었다고 하자. 이때 1번 항목에서 먼저 거부되었으니, 바로 거부되며 100번 항목은 평가치도 않게 된다.

따라서 NACL 규칙 생성시, 미래를 생각하여(=더 우선되는 규칙을 앞단에 삽입할 수 있도록), 번호에 여유(e.g. 100단위)를 두고 부여하는 것이 권장된다.

[stateful && stateless]

네트워크 통신에 있어 서버는 사용자의 상태를 기억하거나/기억하지 않는 전략을 취한다. 상태를 기억해 활용하는 것을 stateful 하다고 하며, 하지 않는 것을 stateless 하다고 한다. 이 둘의 차이점은 다음과 같다.

• stateful : 들어오거나(인바운드) 나갔던(아웃바운드) 요청의 정보를 기억해놓고, 허용되었던 요청에 대한 응답은 규칙에 관계없이 허용한다.
• stateless : 요청을 기억해놓지 않고, 들어오거나 나갈때 항시 규칙을 적용한다. 들어왔지만(인바운드) 나가지(아웃바운드) 못할 수도 있다.

따라서 stateful 방식을 사용하는 경우, 아웃바운드는 열어두고 인바운드만 신경쓰는 경우가 많다. 반면 stateless 방식에서는 인바운드와 아웃바운드를 모두 신경써 관리해주어야 한다. 자칫 실수하면 단방향 통신만 이루어질 수도 있다.

보안그룹

보안그룹은 리소스(e.g. ec2)의 바로 앞에 존재하는 가상 방화벽으로, 지금까지 살핀 라우터, NACL과 같이 트래픽 제어 역할을 수행한다. 보안그룹의 차별점은 "리소스의 바로 앞"으로, 각 리소스별로 다른 설정이 가능하다는 것이다.

예를 들어, 하나의 서브넷에 EC2가 1개 존재하며 트래픽 A만을 허용하고 싶다고 하자. 이 경우에는 굳이 보안 그룹이 없어도 된다. NACL로 허용/차단하거나, 극단적으로 라우팅 테이블에 트래픽 A만을 경로지정해둘 수도 있다.

그러나 하나의 서브넷을 한 개의 EC2가 독점하는 것은 말이 안되는 설계이며, 여러 리소스가 함께 상주하는 것이 일반적이다. 그럼 서브넷에 EC2 A, B가 존재하고 각각 트래픽 A, B만을 허용하고 싶다고 해보자. 이 경우에는 라우터나 NACL로는 해결 방법이 없다. 누군가를 차단하면 한쪽은 트래픽을 전달받지 못하게 되어버린다.

따라서 이런 경우를 상정하여 보안 그룹은 각 리소스들에 별도 부여할수 있도록 되어있다. 이를 통해 리소스들은 각기 원하는 트래픽들만을 허용하는 것이 가능해진다.

또 하나의 큰 특징으로는 규칙 설정을 위한 소스로 IP범위(CIDR)만이 아닌, 관리형 접두사 목록과 다른 보안 그룹을 소스로 사용가능하다는 점이 있다.

관리형 접두사 목록의 경우, 라우팅 테이블에서도 소스로 활용 가능하다. 그러나 앞서 언급하지 않은 것은 라우터는 서브넷의 가장 외부의 통신으로서 여러 경우를 상정해야 하기 때문에, 잘 사용하지 않는 듯 하기 때문이다. 그러나.. 이건 내 가방끈이 짧아서 잘 모르는 것일 수 있다;;

관리형 접두사 목록이란 하나 이상의 CIDR 블록을 모아 놓은 것이다. 이 IP 묶음을 라우터/보안그룹의 소스로 사용할 수 있도록 해주는, 편의성을 돕는 기능이다. 만일 여러 IP들을, 이러한 그룹화 기능없이, 여러 라우터/보안그룹에 각각 추가/삭제해야 했다고 생각해보자. 그 반복 작업만 해도 골치가 아프며, 사람의 실수가 발생할 가능성도 많아진다. 반면 관리형 접두사 목록을 사용했다면, 이 목록만 관리해주면 된다. 라우터/보안그룹은 항시 관리형 접두사 목록을 소스로 사용하기에 변경할 필요가 없는 것이다.

이런 목록화할 수 있는 편의성도 좋지만, 개인적으로는 AWS에서 미리 만들어 놓은 관리형 접두사 목록들을 활용할 수 있다는 점을 매우 좋아한다. CloudFront, Dynamodb, S3, Route53 등의 접두사 목록들이 만들어져 있고 이를 자유롭게 활용가능하다. 예를 들어 나는, 호스팅 중인 앱서버의 보안그룹에 CloudFront 접두사 목록만을 허용해 놓기도 한다. 이 설정을 하면, 정상적으로 Cloud Front를 거쳐 들어오는 요청이 아니라면 모두 차단할 수 있게 되는 것이다.

다른 보안 그룹을 소스로 사용한다는 것은 조금 의아할 수도 있다. 어차피 다른 보안 그룹을 소스로 사용한다면, 그 보안 그룹에서 사용중이던 소스(규칙)를 그냥 가져와 똑같이 적용시키면 되는게 아닌가 싶을 수 있다. 따라서 이 경우도 대표적인(?) 예시로서 설명하겠다.

만일 높은 트래픽, 연산을 분산처리 하기 위해 여러 EC2를 사용한다고 하자. 이때 각각의 EC2가 외부에 연결되어 있으면? 각자의 주소를 가질 것이니 트래픽이 잘 분산될 수 있을리 만무하며, 설사 가능하더라도 이는 사용자들이 게임 서버 선택하듯 시작시 잘 나뉘어 들어가야 하는.. 그러한 수동적인 형태가 될 것이다. 목적 달성이 되었다고 말할 수 없는 것이다.

이럴 때 사용하는 것이 어플리케이션 로드 밸런서이며, 이를 보안그룹과 함께 사용하게 된다. 로드 밸런서에는 외부와 연결이 가능 보안그룹을 붙여놓은 뒤, EC2들에서 사용하는 보안그룹에는 로드밸런서에서 사용 중인 보안그룹을 소스로 사용하는 것이다. 이렇게 하면 서버와 통신하기 위해서는 직접 EC2로 갈 수 없고, 로드 밸런서를 거쳐갈 수 밖에 없게 된다. 그 결과, 대량의 트래픽이 발생해도 로드 밸런서가 트래픽을 분배하여 서버의 부하를 막을 수 있게 되는 것이다.

그 외 각 리소스들은 여러 보안 그룹을 적용받을 수 있다는 특징도 있다. 보안그룹 A, B가 각각 트래픽 A, B를 허용하고 있을때, 리소스에 보안그룹 A, B를 모두 적용시킬 경우 트래픽 A, B를 모두 받아들일 수 있게 된다.

NAT 게이트웨이

NAT란 Network Address Translation의 약어로, 이름 그대로 네트워크 주소(IP) 변환 서비스를 제공한다. NAT 게이트웨이의 주요 특징으로는 퍼블릭 서브넷에 위치하는 서비스라는 것과 내부에서 시작한 트래픽 한정으로 stateful하게 동작한다는 것을 꼽을 수 있다. 예를 들어, NAT 게이트웨이를 활용하면 다음과 같은 방식으로 주소를 변환하며 통신하게 된다.

1. 내부 서버에서 외부와 통신을 원함, 요청을 NAT에 전달
2. NAT은 요청에 사용된 서버의 주소(IP, 포트)를 본인의 주소(NAT IP, 포트)로 변경하고 기록해 둠. 주소가 변경된 요청을 외부로 보냄
3. 외부에서 받고 이를 응답함. 응답은 당연히 패킷에 적혀있던 NAT 주소로 오게 됌
4. NAT는 외부 응답을 기록에서 확인함. 기록된 내역이 있음으로 서버로 보냄
5. 서버가 외부의 응답을 받음

이런 작업을 해주는 것이 NAT 이다. 그럼 이런 번거로운 작업이 필요했던 근본적인 이유는 무엇일까? 이는 서버가 외부와 직접 통신할 수 없는/해서는 안되는 상황이기 때문이다. 세부적인 이유는 NAT 게이트웨이가 사용되는 사례로 알아보자.

※ 사설 네트워크 내부의 여러 서버(호스트)가 하나의 공인 IP를 사용하여 외부에 접속

당연하게도 외부와 통신하려면 공인 IP가 필요하다. 그리고 IP라 함은 지정된 결국 자리수가 정해져 있는 숫자이다. 그리고 자리 수가 지정되었다는 것은 한계가 있다는 뜻이다. 아마 IPv4, IPv6에 대해 들어보았을 것이다. 기존 사용중인 4바이트 IP로는 전세계적인 IP수요가 감당이 안되기 때문에 6바이트로 넘어가고 있는 것이다.

이렇듯 공인 IP는 그 수가 제한적이기에, 많은 서버를 사용중일때 각각 공인 IP를 부여해주기에는 부담이 크다. 이런 경우에 서버들을 내부망 안에 두고, NAT 게이트웨이와 연결해 사용할 수 있다. 그럼 NAT 게이트웨이에 부여된 공인 IP 1개를 사용하여, 내부 서버들 모두 외부와 통신이 가능케 할 수 있다.

부가적으로 이를 활용하면 결국 외부 노출되는 IP는 1개임으로 화이트 리스트 관리도 편해진다는 점도 있다.

※ 프라이빗 서브넷의 서버가 외부와 통신할 수 있도록

프라이빗 서브넷은 당연하게도 앞서 언급한 퍼블릭 서브넷의 반대 개념이다. 서브넷에 연결된 라우터에 인터넷 게이트웨이로 향하는 경로가 없는, 내부망을 말한다.

이 곳에 위치하게 될 서비스들은 기본적으로 보안이 중요시 되는 것들이기에 외부(인터넷)와 연결될 필요가 많지 않다. 그러나 필요하긴 하다. 대표적인 예로 구글, 깃 등으로부터 패키지들을 업데이트/다운로드 받는 일들을 꼽을 수 있다. 이러한 특수한 상황을 위해 프라이빗 서브넷의 라우터에 NAT 게이트웨이 경로를 연결하여 통신을 가능케 해주는 것이다.

개인적으로, 프라이빗 서브넷이 어차피 외부와 연결될 필요가 있었다면 굳이 이렇게 돌아갈 필요가 있나 싶었다. 그냥 퍼블릭 서브넷으로, 인터넷 게이트웨이와 연결해 사용하면 편할테니까. 그.러.나. 이는 내가 잘 몰라서 그렇지, 보안적 관점에서 이 행위가 중요하다는 듯 하다.
먼저 소소하게는 휴먼에러를 최소화 가능하다는 점도 언급된다. 앞서 살펴본 NACL, 보안그룹 등을 활용해 통제할 수도 있겠으나, 이는 까딱 잘못 설정하면 문제될 수도 있다는 것이다.
무엇보다도 외부에 직접적으로 노출되는지 여부는, 보안 관점에서 많은 차이가 있다는 듯 하다. NAT을 사용하면 내부 서버는 외부에 노출된 IP가 없음으로 공격 대상이 될 수조차 없다. 이는 공격 표면 최소화라는 보안 설계 관점과도 맞물린다고 한다. 또한, 설령 NAT 게이트웨이의 IP를 활용해 해킹을 시도하더라도 내부 요청만 stateful하게 처리하는 NAT은 해당 트래픽은 먼저 요청된 적이 없는 트래픽이므로 바로 버린다는 것이다.

---

패킷 이동 관련 서비스 비교

지금까지 살펴본 라우터, NACL, 보안그룹, NAT 게이트웨이 들은 모두 네트워크의 흐름(패킷 이동)에 관여한다.

각각의 것들은 다 다른 역할들은 하지만, 결국은 패킷 이동에 관한 것이기에, 결국은 IP 범위를 통한 제어를 하는 등의 비슷한 설정을 하며 사용하게 된다. 그렇기 때문에, 이 서비스를 이러한 방법으로 사용하면, 굳이 저것은 사용하지 않아도 되지 않나.. 싶을 수도 있다. (적어도 나는 그랬다)

따라서 앞서의 설명으로도 충분하겠지만, 한번 더 각각의 서비스들을 사용해야만 달성 가능한 주요 기능들을 비교/기록해둔다.

서비스	주요 기능	핵심 차별점
라우터	경로 설정	패킷의 경로(길)를 유일하게 알고 있음
NAT 게이트웨이	주소 변환	사설 IP를 공인 IP로 변환
NACL	서브넷 방어	특정 IP를 명시적 차단 가능
보안그룹	인스턴스 방어	인스턴스 별로 세밀한 정책 적용 가능

---

[예시] 프라이빗 EC2의 통신

마지막으로 어떤 방식으로 패킷이 이동하는지 확인해보며 글을 마치겠다. 지금까지 알아본 모든 서비스들이 다 나올 수 있도록, 프라이빗 EC2에서 외부와 통신하는 경우에 발생하는 네트워크 흐름을 작성한다.

다음은 프라이빗 EC2에서 시작된 요청이, 회신되어 돌아온 응답에 관한 흐름이다.

1. 인터넷 게이트웨이: VPC 진입
2. 라우터(퍼블릭 서브넷): 목적지가 NAT IP임을 확인
3. NACL(퍼블릭 서브넷): 패킷 검문(인바운드)
4. NAT 게이트웨이(퍼블릭 서브넷): 패킷 확인, 목적지를 내부 서버로 변경
5. NACL(퍼블릭 서브넷): 패킷 검문(아웃바운드)
6. 라우터(퍼블릭 서브넷): 목적지가 내부 서버임을 확인, 퍼블릭 서브넷의 라우터도 내부망 경로는 보통 알고 있음
7. NACL(프라이빗 서브넷): 패킷 검문(인바운드)
8. 보안그룹(프라이빗 서브넷): 패킷 검문(인바운드), 그러나 stateful하기에 사실상 통과
9. EC2: 응답 도착

위와 같은 흐름으로 응답이 회신되어 들어오게 된다. 그럼 이보다 전 단계인, 요청을 시작할 때에는? 프라이빗 서브넷의 라우터도 이용된다는 것 말고는 큰 차이없이 역순으로 진행되니, 학습 겸 연상해보도록 하자.